Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0086/458.txt

Text File | 1997-04-16 | 19KB | 508 lines

=========================================================================

INFO-ATARI16 Digest         Wed, 18 Apr 90       Volume 90 : Issue  458

Today's Topics:
                          Acc DTA Malloc AES
             FAST ST SPRITES !!!!!!!!!!!!!!!!!!!!!!!!!!!
                      Gemini 1.1 Docs in English
            Help needed with Protobt (XBIOS $12) (2 msgs)
                     INFO-ATARI16 Digest V90 #454
                    in search of a FAST GIF viewer
                            Omega for ST?
          Second request for CX80 Trackball mod information.
                          UUDecode (2 msgs)
----------------------------------------------------------------------

Date: 18 Apr 90 14:27:47 GMT
From:
 zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!dkuug!imada![e-mail]-state.
 edu  (Claus Pedersen)
Subject: Acc DTA Malloc AES
Message-ID: <[e-mail]>

Dear Atarians;
   I am have here the extract of the anwsers to my questions
concerning ACCs, the DTA and malloc:

   - 'fsel_input' can be used without setting the DTA.
   - the size of a file can be found by searching to the end of the
     file.
   - you can use the 'Fsfirst'/'Fsnext' from Accs, by saving the old
     DTA, and then setting your own. Please read letter two...
   - 'Malloc' can't be used from Accs as they are *second class*
     processes, mainly because they don't have a base page.
     This is also the reason why 'Pexec' is rather *unstable* from
     accs. Please read letter one...

The two letters following, are answers to :
      [e-mail]       (Samuel Streeper)
both have been send during the easter, but I keep getting a "User
unknown", when I try to send them.

   Programs have been tested on my MEGA2 w. tos1.4, my brothers STE
w. tos1.6 and my girlfriends MEGA1 w. german tos1.2.  (I don't have
access to an Atari with tos1.0).



************************* LETTER ONE ***************************

    Thank you for answering my questions. I really need to malloc, as
I am making a text editor.
   It is not really an editor yet, which is why I call it "more". I
have not implemented *all* features of the famous "more" - really it
can only open and view files - no fancy stuff at all.
   The only way to avoid malloc is to make a combined ramdisc and
editor. This will of course not solve the problem of having a very
large chunk of unused memory, but it will be more easy to justify (as
many people are using a large fixed size ramdisc, for various
reasons, of which the least is not the lack of a fixed-multi-
megabyte-device.

   I have experimented with the 'active_process'-pointer, and I have
found that it can be used to get the ownership of malloced memory,
and to get a private DTA.
   When using malloc or Fsfirst/Fsnext simply let the
'active_process' point to the basepage of the acc. It works and why
shouldn't it? - Malloc uses the pointer to stamp the memory blocks,
and Basepage allways points to the DTA of choice.

_It really works with both 'Fsfirst' and 'Malloc'._

I use the following code :

    /*****************************************/
    /* Hacks to do what allready is possible */
    /*****************************************/
    extern SYSHDR *Sysbase;
    extern BASPAG *_BasPag;
    BASPAG *OldPD;

    void UseMyBase(void)
    ?
       OldPD = *Sysbase->_run;
       *Sysbase->_run = _BasPag;
    ?

    void UseOldBase(void)
    ?
       *Sysbase->_run = OldPD;
    ?

It is very simple to use, the DTA has to be set one time only:

    main()
    ?
    ...
        UseMyBase();
        Fsetdta(&FileInfo);
        UseOldBase();
    ...
    ?

And here is the interesting part of the 'open file' :

    if (FileSelect(TextPath))
    ?   UseMyBase();
        Err = Fsfirst(TextPath, 0);
        ... (no AES calls) ...
        Text.Document = Malloc( FileInfo.d_length + Epsilon );
        UseOldBase();
        ...
    ?

I didn't want to reenvent the wheel, but I think I just have...
-don't tell me nobody have ever tried to do this before.
   There will be problems if the dispatcher ever runs on a different
scheme (say time sliced). If that ever happens this hack will be in
deep trouble (and so will your suggestion about saving DTA, setting,
using and restoring it)

      old = Fgetdta();
      Fsetdta(new);
      ... do funny things ...
      /* if the dispatcher ever runs here, there will be trouble -
         the sky will spit fire, the earth will open and file
         searches will fail...
      */
      Fsetdta(old);

   However, notice that if the dispatcher was common to both the AES
and GEMDOS there would be no trouble (as there is now). The
dispatcher only needs to update the 'Active_Process' (of GEMDOS
fame), so that it _always_ points to the basepage of the running
process.
   As to my experiment with AC_CLOSE :

>      case AC_CLOSE:
>         Cconws("acc closed");
>         Cconin();
>         form_alert(1,"[1][|Closed][OK]");
>      break;

   What happened was that "acc closed" appeared on the screen before
the application had terminated!, then the desktop was opened (lots of
AES calls), and then the alert box "closed".
   It appears that there is a fixed number of 'free' AES calls, just
after the application is started, and that the dispatcher runs before
AES calls. More interesting it seems that some programs uses the AES
_after_ 'Pterm'! - handy to close windows and restore the desktree -
with the 'etv_term' vektor I guess. This has the added bonus that
windows are closed and the desktree gets restored - even when the
program terminates abnormal (with those cute bombs).


Please let me hear any comments

[e-mail]      (Klaus Pedersen).




************************* LETTER TWO ***************************


    What a bummer, Sorry.

In my last letter I wrote :
>          More interesting it seems that some programs uses the AES
>_after_ 'Pterm'!

    What a bummer - as it is 'appl_exit' that sends the 'AC_CLOSE'
message, the only way to get the acc to get the message, before a new
program starts, is to make AES calls _after_ the 'appl_exit'... It
seems that I am not the only one making bummers.

Sorry, but I was carried away by the perspectives of having a
'etv_term' program doing all the cleaning up :
>                 - handy to close windows and restore the desktree -
>    ...   This has the added bonus that windows are closed and
>the desktree gets restored - even when the program terminates
>abnormal ...

In fact I have tried to have the exit code in the 'etv_term' chain,
using some code looking like this :

        extern void Set_etv_term(void *a);
        extern void (*Old_etv_term)(void);

        void Close( void )
        ?int wind;
            wind = Text.WindId;
            graf_mouse(M_OFF,0);
            wind_close(wind);
            wind_delete(wind);
            menu_bar(M_tree, ME_HIDE);
            graf_mouse(M_ON, 0);
            rsrc_free();
            v_clsvwk(handle);
            appl_exit();
            (*Old_etv_term)();
        ?

        main()
        ?
            Set_etv_term(Close);
            Get_sysbase();
            ...
        ?

    And some assembly to do the dirty work, please note that I use
Turbo C, which uses the registers to pass parameters, when nothing
else has been said (An to pointers, Dn to ints, longs) :

    include "tos.s"
    export Get_sysbase, Sysbase, Set_etv_term, Old_etv_term
        TEXT
    ****** Set Etv_term pointer ******
    Set_etv_term:
        MOVE.L A0, temp
        PEA get_etv_term
        XBIOS supexec, 6; Call Xbios funktion and dealloc 6 bytes
        RTS
    get_etv_term:
        MOVE.L etv_term, Old_etv_term
        MOVE.L temp, etv_term
        RTS

    ****** Get SysBase ******
    Get_sysbase:
        PEA get_sys
        XBIOS supexec, 6
        RTS
    get_sys:
        MOVE.L _sysbase, Sysbase
        RTS

        BSS
    temp:         DS.L 1
    Sysbase:      DS.L 1
    Old_etv_term: DS.L 1


    But the test program bombs out, not these assembly funktions,
they are working. The function 'Close' is called and closes the
window, and then Illustrates the drawback of having code in the
'etv_term' - it bombs (two bombs), and the bomb routine makes an
'Pterm(-1)' in TOS1.4 that is, the 'Pterm' calls the 'etv_term'
vektor, where the 'Close' code are, which bombs and so it goes on.

Any suggestions ?

[e-mail]      (Klaus Pedersen).

------------------------------

Date: 18 Apr 90 17:25:31 GMT
From: earthquake.Berkeley.EDU![e-mail]  (John Kawakami)
Subject: FAST ST SPRITES !!!!!!!!!!!!!!!!!!!!!!!!!!!
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail] () writes:
>
>Hey everyone:
>This one to the ASSEMBLY HACKS out there.
>
>Has anyone written a sprite routine that can beat the Line-A routines
>is the ST?  Without using multiple copies of the sprite offset by 1 pixel
>so that it can be put onto non-byte boundries???
>
>It seems that since the line-a routines are in rom and can be READ faster
>therefor executed faster that this is not possible.  But ive heard people
>claim they can do it.
>
>I would like some psuedo-code or code to do this.
>Code for a monochrome monitor ( 1 BIT PLANE ) would be perferred, just so
>we dont have to mess with the strange way the ST uses 4 bitplanes.
>
>I wrote a routine that put the sprite to the screen byte by byte shifting
>each byte as required.  The line-a  routine was still about 3 times faster
>and my routine only used adds, shifts, and moves.
>
>well, has ANYONE out there done this?




I have not done any ST assembly hacking, but one way to speed up writes of
bitmaps is to pre-shift the bitmap and then write it.  For sprites, which
are presumably all the same size or of several fixed sizes, you can just
pre-shift the sprite (8 times once for each bit) and use the lower three
bits as an index into this array of pre-shifted bitmaps.  (GHOD that's turgid)

In simple terms that even I would understand: instead of taking the bitmap,
shifting it, and writing it; have it set up so you have to "register" the
bitmap, and return a handle, then pre-shift so you don't have to shift
"on the fly", and handle sprite calls by taking the x,y, and handle.

End result: you need to do a bit more pre-processing, but less time is
spent writing to the screen.  Also, you use more memory, but so what!


John Kawakami       [e-mail]
                    ucbvax!earthquake.berkeley.edu!kawakami
                    take-a-right-up-the-hill-then-a-left-on-leroy

------------------------------

Date: Wed, 18 Apr 90 11:55:13 MSZ
From: [e-mail] (Operator Stefan)
Subject: Gemini 1.1 Docs in English
Message-ID: <[e-mail]-ether>

In article <[e-mail]> R. J. Balkwill writes:

> I have translated the docs for Gemini 1.1 (Gemini, Venus and Mupfel)
> from German into English but will not post them unless:
>
> a.  There is interest
>
> b.  A few days go by without objection by the authors of Gemini.

It is very kind of You to translate the documents. But we have made
an english version of the programs to which the docs should refer.
Also, we found someone in the Netherlands who is now translating the
docs. If you don't mind, please send me the docs, so I can change the
names of the dialogs and menu entries.

When we got the english docs, we will beam an english version of
Gemini 1.1 to the world immediately.

  _____________________________________________________
 | Stefan Eissing  <[e-mail]>    +----+  \|#
 | Dorfbauerschaft 7, D-4419 Laer-Holthausen  | OK |   |#
 | "Author of Venus@Gemini"                   +----+   |#
 |_____________________________________________________|#
  #######################################################



------------------------------

Date: 18 Apr 90 10:56:05 GMT
From: mcsun!ukc!harrier.ukc.ac.uk!gos.ukc.ac.uk![e-mail]  (S.H.Cogheil)
Subject: Help needed with Protobt (XBIOS $12)
Message-ID: <[e-mail]>

I am currently trying to write a boot-sector that will make the floppy access
 time 6ms.
However whenever I use the Protobt fucntion I get nothing written to my floppy

Will someone please explain how this Bl**dy function works !

Sam

------------------------------

Date: 18 Apr 90 15:33:30 GMT
From: zaphod.mps.ohio-state.edu!math.lsa.umich.edu![e-mail]
 (Howard Chu)
Subject: Help needed with Protobt (XBIOS $12)
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail] (S.H.Cogheil) writes:
>I am currently trying to write a boot-sector that will make the floppy access
 time 6ms.
>However whenever I use the Protobt fucntion I get nothing written to my floppy
>
>Will someone please explain how this Bl**dy function works !
>
>Sam

Protobt merely generates usable data in the memory buffer you pass it. You
then have to call Flopwrt yourself to get the boot sector written onto the
disk.

Btw, how is one supposed to generate a correct checksum for the boot sector?
My impression from reading the description of Protobt is that it completely
overwrites the contents of the buffer you pass it, so you have to make any
changes (adding executable code, altering the parameter block, etc.) after
the call, and most probably ending up with an invalid checksum. Am I missing
something obvious here?
--
  -- Howard Chu @ University of Michigan

------------------------------

Date: Wed, 18 Apr 90 10:15 EST
From: [e-mail]
Subject: INFO-ATARI16 Digest V90 #454

Please unsubscribe (time to go home) [e-mail]

------------------------------

Date: 18 Apr 90 14:46:34 GMT
From: orion.oac.uci.edu!uci-ics![e-mail]  (Wayne Ngai)
Subject: in search of a FAST GIF viewer
Message-ID: <[e-mail]>

Does anyone has a fast GIF picture viewer for Atari??  If so, please mail
me a copy of it.  I used GIFSHOW, but it's just too slow.   Any of you
familiar with CSHOW gif viewer for IBM??  Anything of that class would
be great!!

Wayne

[e-mail]

------------------------------

Date: 18 Apr 90 17:40:42 GMT
From:
 mailrus!news-server.csri.toronto.edu!utgpu!watserv1!ria!uwovax![e-mail]
 s.ohio-state.edu  (Eric Smith)
Subject: Omega for ST?
Message-ID: <[e-mail]>

In article <[e-mail]>, [e-mail] (Peter Mutsaers) writes:
> I would like to know if someone has ported the game of omega to the ST.
> If so, I would like to hear from it. I am trying to translate it myself,
> but have some problems.
I compiled an older version of it with the gcc. Very few changes were
necessary. However, it was a bit slow (using 16 bit integers would help --
perhaps the MS-DOS version of omega would be a better starting point).
It was also quite buggy; again, the fact that it was an older version
may have something to do with this. At any rate, I can strongly recommend
using the gcc for doing any ports of unix software; the library has a lot
of commonly used unix functions, including a non-multitasking fork().
--
Eric R. Smith                     email:
Dept. of Mathematics            [e-mail]
University of Western Ontario   [e-mail]
London, Ont. Canada N6A 5B7
ph: [phone]

------------------------------

Date: Wed, 18 Apr 90 12:51:24 EDT
From: [e-mail] (Jeffrey K. Long)
Subject: Second request for CX80 Trackball mod information.
Message-ID: <[e-mail]>

This is a second plea for info on modifying an ATARI CX80 (thats eight-zero)
trakball to work as a mouse on the ST.  I have an article for the CX22, but
they seem to be totally different beasts!

Surely someone must have done this mod before !!?? (and I'm sorry for calling
you all Sirley :-) )



------------------------------

Date: 18 Apr 90 12:44:15 GMT
From: cs.dal.ca![e-mail]  (Bill Silvert)
Subject: UUDecode
Message-ID: <[e-mail]>

In article <[e-mail]> [e-mail] (Mickey
 Boyd) writes:
>In article <[e-mail]>, [e-mail] (A.N.Walkeden) writes:
>>I have found a piece of PD software I would like, and have FTP'd it to
>>my machine, where I find it is over 700KBytes in size.
>>Now when I UUDecode this file it produces another output file of similar
>>magnitude, thus there is not enough room for it on a 3.5" disk.
>
>What is the name of the file?  I have never come across that problem, but
>one possible solution (temporary) would be to arc the file on the host
>machine, and then run it from arc on your ST.  I have heard this is
>possible, but I have never done it.

Why not just decode it on the host machine?  If it doesn't have
uudecode, then just port uud, for which portable source coude is readily
available (from me, for example).


--
William Silvert, Habitat Ecology Division, Bedford Inst. of Oceanography
P. O. Box 1006, Dartmouth, Nova Scotia, CANADA B2Y 4A2.  Tel. [phone]
UUCP=..!?uunet|watmath?!dalcs!biomel!bill
BITNET=bill%biomel%dalcs@dalac  InterNet=[e-mail]

------------------------------

Date: 18 Apr 90 16:49:08 GMT
From: samsung!uakari.primate.wisc.edu!larry!gaudi![e-mail]  (Bill
 Mills)
Subject: UUDecode
Message-ID: <[e-mail]>

The best way that I have found to break up large arcs that I uuencode/
decode (since I don't have a hard disk) is to ifng (oops) find someone
with a hard disk.  I have uudecoded files that were too big to fit on
a floppy, then downloaded them to an IBM PC (ugh) at work where I de-arc
them, and then tranfer the files to floppy to use on my ST.  SInce ARC
is the same on MS-DOS as it is for the ST, it makes it that much easier
to find someone with a hard disk (more people with PC systems).  Hope
that helps.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-Bill Mills    [e-mail]  [e-mail]

------------------------------

End of INFO-ATARI16 Digest V90 Issue #458
*****************************************